NOM¶

sshd — démon SSH d'OpenSSH

SYNOPSIS¶

DESCRIPTION¶

sshd (démon SSH) est un démon pour ssh(1). Ces programmes remplacent rlogin et rsh, et fournissent des communications sécurisées et cryptées entre deux machines qui ne sont pas sûres, et ce, sur un réseau non sécurisé. Ces programmes ont pour but d'être les plus simples possibles à installer et à utiliser.

sshd est le démon qui attend des connexions des clients. Il est normalement démarré à l'amorçage de la machine (boot) depuis /etc/rc. Il crée un nouveau démon à chaque connexion entrante. Les démons créés prennent en charge l'échange de clef, le cryptage, l'authentification, l'exécution de commandes et l'échange de données. Cette implémentation de sshd supporte simultanément les versions 1 et 2 du protocole SSH. sshd fonctionne comme décrit ci-après.

FICHIER DE CONFIGURATION¶

sshd lit les données de configuration depuis /etc/ssh/sshd_config (ou le fichier spécifié par l'option -f sur la ligne de commandes). Le format de ce fichier et les options de configuration sont décrits dans sshd_config(5).

PROCESSUS DE CONNEXION¶

Lorsqu'un utilisateur se connecte avec succès, sshd procède comme suit :

1. Si la connexion est sur un terminal et qu'aucune commande n'a été spécifiée, affiche la date de dernière connexion et le contenu du fichier /etc/motd (si accepté dans le fichier de configuration ou en l'absence de $HOME/.hushlogin; Voir la section FICHIERS).
2. Si la connexion est sur un terminal, enregistre la date et l'heure de connexion.
3. Vérifie le fichier /etc/nologin  ; s'il existe, en affiche le contenu et sort (sauf pour root).
4. Bascule pour s'exécuter avec les privilèges d'un utilisateur normal.
5. Paramètre un environnement de base.
6. Lit le contenu du fichier $HOME/.ssh/environment s'il existe.
7. Va dans le répertoire de base (home directory) de l'utilisateur.
8. Si le fichier $HOME/.ssh/rc existe, l'exécute ; sinon, si le fichier /etc/ssh/sshrc existe, l'exécute ; sinon, exécute xauth. Les fichiers « rc » reçoivent le protocole d'authentification et le cookie X11 en entrée standard.
9. Exécute l'interpréteur de commandes (shell) ou la commande.

FORMAT DU FICHIER AUTHORIZED_KEYS¶

$HOME/.ssh/authorized_keys est le fichier par défaut qui liste les clefs publiques autorisées pour l'authentification RSA pour la version 1 du protocole, et pour l'authentification par clef publique (PubkeyAuthentication) pour la version 2 du protocole. On peut utiliser l'option AuthorizedKeysFile pour spécifier un autre fichier de configuration.

Chaque ligne du fichier contient une clef (les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires). Chaque clef publique RSA consiste en les champs suivants, séparés par des espaces : options, bits, exposant, modulo, commentaire. Chaque clef publique pour la version 2 du protocole consiste en : options, type de clef, clef encodée en base64, commentaire. Les champs d'option sont optionnels ; leur présence est déterminée par le fait que la ligne commence avec un nombre ou pas (le champ d'option ne commence jamais par un nombre). Les champs bits, exposant, modulo et commentaire déterminent la clef RSA pour la version 1 du protocole ; le champ commentaire n'est pas utilisé pour quoi que ce soit (mais peut servir à l'utilisateur pour identifier sa clef). Pour la version 2 du protocole, le type de clef est « ssh-dss » ou «ssh-rsa ».

Note : les lignes contenues dans ce fichier font en général quelques centaines de caractères (à cause de la taille du modulo de la clef RSA). Il n'est pas très judicieux de les saisir manuellement ; il est plus fiable de les copier dans les fichiers identity.pub, id_dsa.pub ou id_rsa.pub puis de les coller.

sshd impose une taille minimale du modulo pour la clef RSA pour la version 1 du protocole et pour les clefs pour la version 2 du protocole de 768 bits.

Les options (s'il y en a) consistent en une liste d'entrées séparées par des virgules. Les espaces sont interdits, sauf entre des guillemets. Les spécifications d'options suivantes sont supportées. Note : les mots-clefs des options ne sont pas sensibles à la casse.

from="pattern-list"

Spécifie qu'en plus de l'authentification RSA, le nom canonique de la machine distante doit figurer dans la liste des motifs séparés par des virgules (« * » et «? » sont des jokers). La liste peut aussi contenir des motifs précédés par l'opérateur de négation « ! » ; si le nom canonique de la machine correspond au motif nié, on n'accepte pas la clef. Le but de cette option est éventuellement d'améliorer la sécurité : l'authentification RSA en elle-même ne permet pas d'avoir confiance dans le réseau ou les serveurs de noms ou quoi que ce soit (à part la clef) ; par contre, si quelqu'un vole la clef, cette clef lui permet de se connecter depuis n'importe où dans le monde. Cette option supplémentaire rend encore plus difficile l'utilisation d'une clef volée (les serveurs de noms et/ou les routeurs peuvent avoir été compromis en plus de la clef elle-même).

command="commande"

Spécifie que cette commande doit être exécutée si on utilise cette clef pour s'authentifier. La commande fournie par l'utilisateur (s'il y en a une) est ignorée. La commande est exécutée sur un pseudo-terminal (pty) si le client a demandé un pseudo-terminal ; sinon elle est exécutée sans terminal. Si on a besoin d'un canal 8-bits propre, on ne doit pas demander de pseudo-terminal, ou alors on spécifie no-pty. On peut inclure une apostrophe (« ' ») dans la commande en la faisant précéder d'une anti-barre (« \ »). Cette option peut être utile pour restreindre à des actions spécifiques. Par exemple, une clef peut n'autoriser qu'à effectuer des sauvegardes distantes, mais rien d'autre. Note : le client doit spécifier des redirections TCP/IP ou X11 sauf s'ils sont explicitement interdits. Cette option s'applique à l'exécution d'un interpréteur de commandes (shell), d'une commande ou d'un sous-système.

environment="NAME=value"

Spécifie que la chaîne de caractère doit être ajoutée à l'environnement lors de la connexion en utilisant cette clef. Les variables d'environnement définies de cette manière outrepassent les autres variables d'environnement par défaut. On peut spécifier plusieurs de ces options. Cette option est désactivée automatiquement si l'option UseLogin est activée.

no-port-forwarding

Interdit les redirections TCP/IP si on utilise cette clef pour l'authentification. Toute demande de redirection de port de la part de l'utilisateur retournera une erreur. Ceci peut être utilisé par exemple pour une connexion avec l'option command.

no-X11-forwarding

Interdit les redirections X11 si on utilise cette clef pour l'authentification. Toute demande de redirection X11 de la part de l'utilisateur retournera une erreur.

no-agent-forwarding

Interdit les redirections de l'agent d'authentification si on utilise cette clef pour l'authentification.

no-pty

Empêche l'allocation de terminal (toute demande d'allocation d'un terminal virtuel échouera).

permitopen="host:port"

Limite les redirections de port « ssh -L » locales de telle manière qu'il n'est possible de se connecter qu'à la machine et au port spécifiés. On peut spécifier des adresse IPv6 avec une autre syntaxe : host/port. On peut spécifier plusieurs options permitopen en les séparant par des virgules. Aucune correspondance n'est effectuée sur les noms de machines, ils doivent être des adresses ou des domaines littéraux.

FORMAT DU FICHIER SSH_KNOWN_HOSTS¶

Les fichiers /etc/ssh/ssh_known_hosts, et $HOME/.ssh/known_hosts contiennent les clefs publiques de toutes les machines connues. Le fichier global doit être préparé par l'administrateur (éventuellement), mais le fichier de l'utilisateur est mis à jour automatiquement : dès que l'utilisateur se connecte depuis une machine inconnue, elle est ajoutée au fichier de l'utilisateur.

Chaque ligne de ces fichiers contient les champs suivants : noms de machine, bits, exposant, modulo, commentaire. Les champs sont séparés par des espaces.

Les noms de machines sont une liste de motifs séparés par des virgules (« * » et « ? » sont des jokers) ; chaque motif l'un après l'autre est mis en correspondance avec le nom canonique de la machine (authentification d'un client) ou avec le nom fourni par l'utilisateur (authentification d'un serveur). On peut précéder un motif du caractère « ! » pour indiquer une négation : si le nom de la machine correspond à un motif nié, il n'est pas accepté (de par cette ligne), même s'il correspond à un autre motif de la ligne.

Les bits, exposant, et modulo sont pris directement dans la clef de machine RSA ; on peut les récupérer par exemple, depuis /etc/ssh/ssh_host_key.pub. Le champ de commentaire optionnel continue jusqu'à la fin de la ligne et n'est pas utilisé.

Les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires.

Lors d'une authentification de machine, l'authentification est acceptée si une ligne a la clef appropriée. Il est donc autorisé (mais pas recommandé) d'avoir plusieurs lignes ou des clefs de machines différentes pour les mêmes noms. Cela se produit inévitablement quand on met dans le fichier les noms abrégés des noms de machines depuis des domaines différents. Il est possible que le fichier contienne des informations en conflit ; on peut s'authentifier si on trouve une information valide dans l'un des fichiers.

Note : les lignes dans ces fichiers contiennent typiquement des centaines de caractères, et il n'est pas très intéressant de les saisir manuellement. On peut plutôt les générer à l'aide d'un script, ou les récupérer dans /etc/ssh/ssh_host_key.pub et les ajouter en tête du fichier.

closenet,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234.....=

FICHIERS¶

/etc/ssh/sshd_config

Contient les données de configuration pour sshd. Le format du fichier et les options de configuration sont décrites dans sshd_config(5).

/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key,

/etc/ssh/ssh_host_rsa_key Ces trois fichiers contiennent les parties privées des clefs de la machine. Ces fichiers sont la propriété de root, sont lisibles par root, et non accessibles aux autres. Note : sshd ne démarre pas si ce fichier est accessible au groupe et/ou aux autres.

/etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub,

/etc/ssh/ssh_host_rsa_key.pub Ces trois fichiers contiennent les parties publiques des clefs de la machine. Ces fichiers doivent être lisibles par tous, mais accessibles en écriture à root uniquement. Leur contenu doit correspondre à leur partie privée respective. Ces fichiers ne sont pas vraiment utilisés ; ils sont fournis par commodité pour l'utilisateur qui peut les copier dans ses fichiers des machines connues. Ces fichiers sont créés par ssh-keygen(1).

/etc/moduli

Contient les groupes Diffie-Hellman utilisés pour le "Diffie-Hellman Group Exchange".

/var/empty

répertoire chroot(2) utilisé par sshd lors de la séparation de privilèges dans la phase de pré-authentification. Le répertoire ne doit contenir aucun fichier, est la propriété de root et n'est pas accessible en écriture au groupe ou aux autres.

/var/run/sshd.pid

Contient d'identifiant du processus (PID) du démon sshd en attente de connexions (si plusieurs démons sont en cours d'exécution en même temps sur plusieurs ports, ce fichier contient l'identifiant du dernier processus démarré). Le contenu de ce fichier n'est pas sensible ; il peut être lisible par tout le monde.

$HOME/.ssh/authorized_keys

Liste les clefs publiques (RSA ou DSA) utilisables pour se connecter avec le compte de l'utilisateur. Ce fichier doit être lisible par root (ce qui peut signifier lisible par tout le monde sur quelques machines si le répertoire de base de l'utilisateur est sur un montage NFS). Il est recommandé qu'il ne soit pas accessible aux autres. Le format de ce fichier est décrit ci-avant. Les utilisateurs y mettent le contenu de leurs fichiers identity.pub, id_dsa.pub et/ou id_rsa.pub, comme décrit dans ssh-keygen(1).

/etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts

Ces fichiers sont consultés si on utilise les rhosts avec une authentification par machine ou une authentification par machine pour la version 2 du protocole pour vérifier la clef publique de la machine. La clef doit être listée dans un de ces fichiers pour être acceptée. Le client utilise les mêmes fichiers pour vérifier qu'il se connecte à la bonne machine distante. Ces fichiers ne doivent être accessibles en écriture que par root et leur propriétaire. /etc/ssh/ssh_known_hosts doit être lisible par tout le monde, et $HOME/.ssh/known_hosts peut être accessible en lecture à tout le monde, mais ce n'est pas nécessaire.

/etc/nologin

Si ce fichier existe, sshd empêche quiconque de se connecter, à l'exception de root. Le contenu de ce fichier est affiché à quiconque essaie de se connecter, et les connexions non-root sont refusées. Le fichier doit être lisible par tout le monde.

/etc/hosts.allow, /etc/hosts.deny

Les contrôles d'accès qui peuvent être appliqués par tcp-wrappers sont définis dans ces fichiers. Pour plus d'informations, voir hosts_access(5).

$HOME/.rhosts

Ce fichier contient les paires machine/nom d'utilisateur, séparées par un espace, une par ligne. L'utilisateur spécifié sur la machine correspondante est autorisé à se connecter sans mot de passe. le même fichier est utilisé par rlogind et rshd. le fichier doit être accessible en écriture seulement à l'utilisateur ; il est recommandé qu'il ne soit pas accessible aux autres.

Il est aussi possible d'utiliser des groupes réseau (netgroups) dans le fichier. Le nom de machine ou d'utilisateur peut être de la forme +@groupname pour spécifier toutes les machines ou tous les utilisateurs dans le groupe.

$HOME/.shosts

Pour ssh, ce fichier est exactement le même que .rhosts. Cependant ce fichier n'est pas utilisé par rlogin et rshd, donc son utilisation ne permet que des accès par SSH.

/etc/hosts.equiv

Ce fichier est utilisé pendant l'authentification .rhosts. Dans la forme la plus simple, ce fichier contient des noms de machine, un par ligne. Les utilisateurs sur ces machines sont autorisés à se connecter sans mot de passe, pour peu qu'ils aient le même nom d'utilisateur sur les deux machines. Le nom de machine peut aussi être suivi d'un nom d'utilisateur ; ces utilisateurs sont autorisés à se connecter sous n'importe quel nom d'utilisateur sur cette machine (à l'exception de root). En outre, la syntaxe « +@group » peut être utilisée pour spécifier des groupes réseau. Les entrées niées commencent avec « - ».

Si la machine/l'utilisateur client(e) est mis(e) en correspondance dans ce fichier, la connexion est automatiquement autorisée, pour peu que les noms d'utilisateur client et serveur soient identiques. En outre, une authentification de machine RSA réussie est normalement requise. Ce fichier ne doit être accessible en écriture qu'à root ; il est recommandé qu'il soit accessible en lecture par tout le monde.

Attention : Ce n'est presque jamais une bonne idée d'utiliser des noms d'utilisateurs dans" hosts.equiv. Il faut bien être conscient du fait que cela signifie vraiment que le ou les utilisateur(s) peuvent se connecter en tant que n'importe qui, et en particulier bin, daemon, adm, et les autres comptes propriétaires de binaires et de répertoires critiques pour le système. L'utilisation d'un nom d'utilisateur accorde pratiquement un accès de l'utilisateur root. La seule utilisation raisonnable des noms d'utilisateurs réside dans les entrées niées.

Note : Cet avertissement s'applique aussi à rsh/rlogin.

/etc/ssh/shosts.equiv

Ce fichier est traité exactement de la même manière que /etc/hosts.equiv. Néanmoins, ce fichier peut être utile dans des environnements dans lesquels on souhaite utiliser rsh/rlogin et ssh.

$HOME/.ssh/environment

Ce fichier (s'il existe) est lu dans l'environnement lors de la connexion. Il peut ne contenir que des lignes vides, des lignes de commentaires (qui commencent par le caractère « # »), et des lignes d'affectations de la forme nom=valeur. Le fichier ne doit être accessible en écriture qu'à l'utilisateur ; il n'a pas besoin d'être accessible en lecture au groupe ou aux autres.

$HOME/.ssh/rc

Si ce fichier existe, il est exécuté avec /bin/sh après lecture des fichiers d'environnement, mais avant de démarrer l'interpréteur de commandes (shell) ou la commande de l'utilisateur. Il ne doit pas produire de sortie sur la sortie standard (stdout) ; on doit plutôt utiliser l'erreur standard (stderr). Si des redirections X11 sont en cours, il recevra la paire « proto cookie » en entrée standard (et DISPLAY dans son environnement). Le script doit appeler xauth(1) parce que sshd n'exécutera pas automatiquement xauth pour ajouter des cookies X11.

Le but premier de ce fichier est d'exécuter toutes les routines d'initialisation qui peuvent nécessaires avant que le répertoire de base (home directory) de l'utilisateur ne devienne accessible ; AFS fournit un exemple particulier d'un tel environnement.

Ce fichier contiendra probablement du code d'initialisation suivi par quelque chose comme :

if read proto cookie && [ -n "$DISPLAY" ]; then
	if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
		# X11UseLocalhost=yes
		xauth add unix:`echo $DISPLAY |
		    cut -c11-` $proto $cookie
	else
		# X11UseLocalhost=no
		xauth add $DISPLAY $proto $cookie
	fi
fi

Si ce fichier n'existe pas, /etc/ssh/sshrc est exécuté, et s'il n'existe pas non plus, xauth est utilisé pour ajouter le cookie.

Ce fichier ne doit être accessible en écriture qu'à l'utilisateur, et n'a pas besoin d'être lisible par le groupe ou les autres.

/etc/ssh/sshrc

Identique à $HOME/.ssh/rc. Ce fichier peut être utilisé pour spécifier globalement des initialisations pour la connexion spécifiques à une machine. Ce fichier ne doit être accesible en écriture qu'à root et lisible par tous.

AUTEURS¶

OpenSSH est dérivé de la version originale et libre ssh 1.2.12 par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bugs, ré-ajouté des nouvelles fonctionnalité et créé OpenSSH. Markus Friedl a contribué au support des versions 1.5 et 2.0 du protocole SSH. Niels Provos et Markus Friedl ont contribué au support de la séparation de privilèges.regénéré

TRADUCTION FRANÇAISE¶

Laurent GAUTROT <l dot gautrot at free dot fr> 05/12/2002 Il est possible que cette traduction soit imparfaite ou périmée. En cas de doute, veuillez vous reporter au document original en langue anglaise fourni avec le programme.

VOIR AUSSI¶

scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), login.conf(5), moduli(5), sshd_config(5), sftp-server(8) T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January 2002, work in progress material. M. Friedl, N. Provos, and W. A. Simpson, Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol, draft-ietf-secsh-dh-group-exchange-02.txt, January 2002, work in progress material.